home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2338 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.1 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS frien
  5. Date: 30 Jan 1996 10:58:01 +0100
  6. Organization: dis-
  7. Message-ID: <4ekq39$nh@serpens.rhein.de>
  8. References: <4ekcr9$1q6@sinsen.sn.no>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. tbk@sn.no (Thore Bjerklund Karlsen) writes:
  12.  
  13. >>You are already dead at that point because you don't know how to
  14. >>handle incoming interrupts.
  15.  
  16. >What?!  Why not?
  17.  
  18. Because you don't know how to control the hardware that is sending
  19. interrupts. After all there _is_ hardware beyond the basic A1200, no ?
  20.  
  21. >>>C0d3rz  that  produce  bad code are not C00l at all.
  22. >>No ? But they act as if they were.
  23.  
  24. >That's  just  their  personality,  has nothing to do with the safety of
  25. >hardware-banging.
  26.  
  27. I disagree.
  28.  
  29. >>Not more than when banging hardware. Well, maybe more because you
  30. >>have more things you can do.
  31.  
  32. >Not  more?   There are a zillion more things to take into consideration
  33. >when doing OS-programming.
  34.  
  35. Same for hardware programming. But the real thing is that OS programming
  36. is much easier because usually you do NOT have to consider a zillion things.
  37.  
  38. If you want to hack around the OS _then_ you get into extra work.
  39.  
  40. >Have you done any HW-programming at all?
  41. >I have done both, and I know the difference.
  42.  
  43. Well, I know that with HW programming (especially c0d3r style) you have
  44. to think about much more.
  45.  
  46. >>>It's  their  incompetence  that makes everything incompatible, it's no
  47. >>>because they don't use the OS to set every pixel.
  48. >>I don't say anything else. Believe me.
  49. >It certainly seems like you are.
  50.  
  51. I don't.
  52.  
  53. >>Unfortunately not. Your simple description above is already CRAP.
  54.  
  55. >Then tell me what's crap about it.
  56.  
  57. Read my explanation about interrupts.
  58.  
  59. >How  would  Turrican  2  be  using only the OS?  Shadow of the beast 3?
  60. >Somehow I doubt it could have been done with the OS.
  61.  
  62. Maybe not exactly but pretty close.
  63.  
  64. >>>use  PutPixel()  or  whatever  (I  don't even know the name)
  65.  
  66. >>That's the problem. You do not even _know_ it (but you are too sure
  67. >>that it is too slow).
  68.  
  69. >I KNOW it is slow!
  70.  
  71. or whatever...
  72.  
  73. >A general PutPixel-routine IS slow, no matter if it
  74. >is  your  own  or  the  OS-routine.  This has nothing to do with the OS
  75. >itself.
  76.  
  77. Then why do you assume that you have to use it with the OS ?
  78.  
  79. >>Simply assuming things makes you chose the
  80. >>wrong methods. Simply assuming things made you post the above
  81. >>description how to take over the machine.
  82.  
  83. >It has worked for me..
  84.  
  85. Yes. That is the problem. You used it "because it has worked for you".
  86. C0d3rz do these assumptions. If it works for them it must be correct.
  87. That's why games have so many problems to run on anything else but
  88. the basic A500 or A1200 hardware.
  89.  
  90. >>Still rubbish. Even when you think it needs 100% of an A500 or A1200
  91. >>it won't need 100% of an A4000.
  92.  
  93. >Blitter speed doesn't improve with the A4000..
  94.  
  95. So what ? There is more than just blitter operations in a game and people
  96. with graphics cards might even have a "blitter" that is much faster.
  97.  
  98. >Yes,  because  the system can't even scroll a simple 1bpl screen in one
  99. >frame on the A500.  Who wants a jerky game?
  100.  
  101. Do you use PutPixel() to scroll ? Seems you are.
  102.  
  103. >Wonder  why  noone  tried.
  104.  
  105. As you wrote: "That's  just  their  personality".
  106.  
  107. >using the OS?  It surely can't be because all coders have big egos.
  108.  
  109. That's the major reason.
  110.  
  111. >>>Oh,  I ignore machines that are more powerful? Nothing could be furthe
  112. >>>from the truth.
  113.  
  114. >>Rubbish.
  115.  
  116. >Why?
  117.  
  118. Read above the section about interrupts. That's maybe not an impressive
  119. example but it is a valid one.
  120.  
  121. >>I seriously believe that you do not care about compatibility.
  122. >>If it runs for you (or with commercial background: for most of
  123. >>the customers) it is enough.
  124.  
  125. >Why would I want to code anything that only runs on my own machine?
  126.  
  127. I don't know. But as it seems you are satisfied when it runs on your
  128. machines. With your words: "It has worked for me".
  129.  
  130. >>Maybe it is not fast enough (which I don't believe and which is only
  131. >>half of the story anyway). But the problem is that this argument comes
  132. >>independent of the hardware you do have which simply means that the
  133. >>argument is wrong and you must have another reason.
  134.  
  135. >Sorry, I don't really understand what you're trying to say here..
  136.  
  137. The argument "not fast enough" comes independent of hardware. When c0d3rz
  138. had A500s then hardware wasn't fast enough because not everyone had an 68020
  139. (probably because 68020 were the fastest 68k CPU at that time).
  140. Now that they have A1200s they reject using the system because not everyone
  141. had an 68040 (or 68060 since that was available).
  142. So it doesn't matter what hardware they actually have because it would never
  143. be "fast enough" in their argumentation. This is illogical and shows that
  144. hardware speed has little influence on the c0d3rz decision to junk the operating
  145. system. They do it because the want to do it. Ideology, whatever. But surely
  146. the reason is not a technical one.
  147.  
  148. Regards,
  149. -- 
  150.                                 Michael van Elst
  151.  
  152. Internet: mlelstv@serpens.rhein.de
  153.                                 "A potential Snark may lurk in every tree."
  154.